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1.0 INTRODUCTION 

1.1 SCOPE 

This report suranarizes the development and operation of the SND III 
Data System which included the Onboard Data Systems (ODS), Payload 
Operations Control Center (POCC)* Data Systesm, Science Operations 
Remote Center (SORC)** Data Systems, Data Links, Slow Scan TV, Data 
Library functions, and the ICDICS statusing system. 

1.2 OBJECTIVES 

The original objective of the data handling systems for the SMD III 
test was to develop a permanent facility for SMD tests that would 
functionally simulate all elements of the Shuttle onboard, telemetry, 
and ground data systems that are involved with Spacelab operations. 

It was determined rather quickly that this ambitious objective was 
unattainable because the end-to-end system for payloads was not well 
defined, funds for a high fidelity permanent facility were not avail- 
able, and the time to acquire new computer equipment before the SMD III 
test was too short. 

With these considerations in mind, a new objective was formulated 
to develop data handling systems using existing equipment that would 
functionally simulate the applicable elements of the Shuttle Data 
systems, these simulated end-to-end elements included the: 

1) Onboard Data Systems 

2) Data Downlinks 

3} Ground Data Systems 

4) POCC Science Processing System 

5) POCC-SORC Data Link 

6) SORC Science Processing System 

7) Data Storage and Retrieval System 


* The POCC was located at the Johnson Space Center in Houston, Texas. 

** The SORC was located at the Ames Research Center at Moffett Field, 
California. 
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1.3 APPLICABLE DOCUMENTS 


The following SMD III unique documents are referenced in this 
report. Copies may be found in the Space Life Sciences Archival 
Library in Room 2-203. Bldg. 37. Johnson Space Center. Mail Code 
JH65, Phone (713)483-2889. 


SD-SMD-III-001 
SD-SMD-I 11-002 
SD-SMO-III-005 
SD-SMD-I I 1-006 


Experiment Parameters and Patch Panel 
Configurations 

Data Display and Printer Formats, 
Calibration and Limit Sensing Data 

Onboard Data System/Ground Data 
System Design Data 

Telemetry Downlink Locatio'S 

Science Computer Software System for 
SMD III 
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2.0 SUMMARY 


The long term objective for the data system was to develop a per- 
manent facility for SMD tests that would simulate all elements of 
the Shuttle onboard, telemetry, and ground data systems that are 
involved with Spacelab operations. This objective proved to be 
unattainable for SMD III because the end-to-end system for payloads 
was not well defined, funds for a high fidelity permanent facility 
were not available, and there was not enough lead time to obtain 
new computer equipment prior to the start of SMD III. It was de- 
cided to develop a data system, using available equipment as much 
as possible, that would functionally simulate the applicable elements 
of the Shuttle data systems. 

The Onboard Data System (ODS) and the Ground Data System (GDS) were 
developed by the Ford Aerospace Corporation using two Varian 620i 
computers that were at least ten years old. The air-to-ground link 
was simulated by a hardwired computer -to -computer interface. Due 
to the limited core and A-to-D capability of the ODS, it was ground 
ruled that only a single active experiment would be downlinked at a 
time. A patch board system was used on board to select experiment 
inputs, and the downlink configuration from the ODS was changed by 
a crew keyboard entry to support each experiment. The ODS provided 
a CRT display of experiment parameters to enable the crew to monitor 
experiment performance. An onboard analog system, with recording 
capability, was installed to handle high rate data and to provide 
a backup to the digital system. Tne GDS attempted to simulate POCC 
functions that will be available in Mission Control. It accomplished 
engineering unit conversion and limit sensing, and provided real- 
time parameter display on CRT's in the Science Monitoring Area (POCC) 
and the Test Control Area. The GDS also provided an output to the 
Science Processing System. The Science Processing System was developed 
by Technology, Inc., using a PDP-11/40. It was intended to provide 
a link to the Science Operations Remote Center (SORC) computer at 
the Ames Research Center (ARC), and to provide graphics parameter 
display in the POCC. The graphics display capability was not imple- 
mented due to development problems, but the ARC link functioned 
normally throughout the test. The link between the Science Computer 
and the SORC computer utilized a conditioned telephone line. The 
SORC computer provided tabular and graphic CRT displays and strip 
charts for the principal investigators at ARC. 

The operation of the Data System was coordinated by the Data Manager 
under the direction of the Science Mcnager. The ODS and GDS were 
operated by Ford Aerospace personnel and the Science computer was 
operated by Technology, Inc. personnel. 

The development and implementation of the Data System was hampered 
by a shor ^e of funds, schedule limitations and other difficulties. 
Even so, ii, performed well and proved the value of real-time experi- 
ment monitoring. The principal investigators were able to monitor 
the performance of their experiments and offer assistance where needed. 
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3.0 RESULTS 

3.1 JOHNSON SPACE CENTER 

3.1.1 General 


Prior to and during the test a major concern was that the data sub- 
systems were in series with no redundancy so that a failure anywhere 
would preclude data from the next link. Additionally, the ODS and 
GOS used minicomputers at least 10 years old which are no longer 
actively supported by the manufacturer and with little systems soft- 
ware to aid in writing application software. 

Fortunately, these concerns were not necessary since they both 
worked very well throughout the test with only 20 minutes of data 
lost in a period between experiment runs. The data lost was Spacelab 
environmental data and experiment background data and its loss had 
no impact at all on experiment results. 

Aside from one drum hardware failure in the ODS, no hardware failures 
occurred. Additionally, the software performed all functions 
required and some new software was added (e.g. , display raw voltages, 
drive auditory alarm, etc.) as the test progressed. Prior to the 
test, it was decided that the ODS and GDS would be "throw-away" 
systems because of the age of these systems. Despite their excellent 
performance in this test, that decision still appears sound because 
they lack the fidelity required for real payloads. 

The POCC Science Processing System (Science Computer) was plagued 
with developmental problems, e.g., missed delivery, inadequate 
testing, application software bugs, etc. Once these problems were 
overcome, the system performed well, completing all the functions 
established except the graphics display. No hardware failures 
occurred during the test and no data was lost. 

Like the Science Computer, the SORC Science Processing System 
experienced numerous developmental problems with hardware failures 
on almost each peripheral during Phase Training, the two-day simula- 
tion and SMD III. Despite this, the only failure which impacted the 
SORC occurred during the second day resulting in the loss of six 
hours of background data. All lost data was recovered from ODS log 
tapes after the test. The high speed data link went down only once 
during the SORC operations. 

With respect to the MEDICS storage end retrieval system, it functioned 
as expected with no hardware problems except a stuck key on one term- 
inal which was readily fixed. Finally, the analog system performed 
all functions with only minor hardware problems. 
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3.1.2 Discussion 


The total collection of systems put together by teams of contractors 
using existing eq ipment generally performed well, however, the real 
question is what was learned from the exercise that can be applied 
to preparing a data capability for the Shuttle era in life sciences. 

Certainly the test showed that all elements (systems) developed are 
needed for an effective life sciences program. The value of real- 
time monitoring from the engineering and operational management 
point of view was never really questioned, as this has been demon- 
strated in many other NASA programs. Since the capital investment 
is typically high, the value from the scientist viewpoint can be 
more readily questioned. Prior to the test, most scientific inves- 
tigators expressed skepticism that real time local or remote 
monitoring of the experiments was needed. It seemed apparent that 
they felt reassured about the quality of their research data by 
monitoring it during collection. Additionally, the real time 
summary statistics, ground stripcharts and CRT displays gave them 
the ability to identify problems in real time. Without this sort 
of capability, much useless and perhaps misleading scientific 
information will be collected. 

Because of constraints (time, money, etc.) it was decided very 
early to use limited bandwidth phone lines to get information to 
the re>^otely located scientist. This limitation restricted users 
from tracking some raw data, caused a 3-5 minute delay in seeing 
the real-time problems, some synchronization problems, and limited 
TV coverage due to slow scan. While fixes were made to these 
problems, increasing the bandwidth should be considered with some 
cost/benefit analyses as the experiment program firms up. 

Another area where considerable learning from the test occurred 
was in interfacing experiments to the onboard data system. Some 
problems that occurred in interfacin'^ were common grounding, 
single vs. differential analog inputs; voltage regulation, and 
scaling for computer input, late delivery, writing software to 
provide raw voltage displays on the ground; acquiring, controlling, 
testing, and changing experiments calibration data. Given that we 
will be interfacing numerous experiments in relatively short periods 
of time, this area must be streamlined including precise definition 
of interface options and a life sciences users guide with pictorial 
representation of options and common errors made in interfacing. 
Consideration should be given to developing independent low cos'" 
optional interface test unit(s) that could be put in core and loaned 
to experimenters during their experiment development stage. 

During the early phase of SMD III program development, a policy 
was developed that all experiments must have their own display 
equipment that is independent of the onboard data systems display. 
The results were a wide variety of digital and analog meters. 
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oscilloscopes, hardcopiers, stripcharts and CRT's with each consu- 
ming variable amounts of power. It was clear from the exercise 
that much remains to be done in selecting and flight qualifying 
such displays for use as loaned core equipment. Additionally, 
the use of onboard stripcharts validated the need for this equipment 
over digital CRT displays because the hhrdcopy display provides a 
short range historical record, non-el ectronic annotation can be 
made, and scientists within many branches of life sciences are 
familiar with this tool. Ground based stripcharts, both at JSC 
and Ames, once again demonstrated their value to the scientific 
community. 

While no serious problems occurred during this test, the amount 
of worry about computer failures (as well as the cost of standby 
computer maintenance personnel) strongly suggest that high capital 
investment is wise to obtain reliable equipment for a permanent 
facility to be frequently used over the shuttle era. Redundancy of 
all or portions of the data system is clearly needed and a failure- 
mode analysis should be part of the implementing contractor's 
st-jdy. 

Finally, the systems implement d were only a crude representation 
of what will actually be available. It was somewhat surprising 
that several very old minicomputers and seveval inexpensive new 
minicomputers could meet the needs of the experiments almost as 
well as the expensive systems actually planned (e.g., 3 French 
Flight computers, 4 IBM Flight computers, 4-6 Interdata ground 
computers, 3-5 large IBM computers, and 1 large CDC computer). 

The surprise however, disappears when one considers they must meet 
the ncnds of all of NASA over a 10 year period. 

What level of flight data systems fidelity is needed for Level IV 
integration? The SMD III does not provide an answer to this 
question. It provided an extreme lower limit — in fact, below a 
minimum since no one would suggest we could use the same systems 
over an extended time frame. In effect, current unknowns in the 
program will help define this level, e.g., how much money will 
be available, what requirenk*nts will be placed on such systems, 
what use can be made of other NASA systems under development, etc. 
While the SMD III test did not answer all the questions, it proved 
to be extremely valuable in helping us define where more work, 
studies, and thought are necessary. 

3.2 AMES RESEARCH CENTER 
3.2.1 General 


The SMD III objectives included the establishment and operation of 
a "remote ground station" (which became known as the Science 
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Operations Remote Center - SORC) at Ames Research Center. The 
detailed planning for the SORC started less than 5 months prior 
to the SMD III test. It was fortunate that ARC had sufficient 
resources to provide most of the equipment needed to operate the 
SORC thus avoiding long procurement cycles. There was, however, 
a finite limit on what wa> available and, as a consequence, there 
was little or no back-up equipment readily available. Several 
areas were left vulnerable as a result; i.e., no backup computer 
capability at either the SORC or JSC, only one high speed data 
link, no backup equipment for CRT displays, etc. The fact that 
major failures did not occur during the SMDIII test was fortuitous. 
Major failures certainly would have resulted in real-time data 
loss to the P.I. As it was, the SORC received, logged, processed 
and displayed experiment data in real time for the various P.I.'s 
in the SORC. The capability of the SORC to do that in a r^'utine 
manner and for the P.I.'s in the SORC to interact with the crew 
was amply demonstrated throughout the seven day SMD III test. 

3.2.2 Discussion 

3. 2. 2.1 Data Acquisition 

Data acquisition was in general as planned. 

The reliability of the high speed data link was surprisingly high. 

The reliability of the rest of the data system has to be rated 
satisfactory to good, i.e., about as expected. The quality of 
the data was acceptable as would be expected of digital data. 
Occassional delays of some minutes (5 to 7) were experienced and 
attributed to computer crashes at JSC and the SORC and switching 
the SORC computer from off-line processing and software development 
back to real time data handling. Such delays seemingly had no 
impact on the experiment nor caused the P.I.'s undue consternation. 

3. 2. 2. 2 Data Processing 

Data processing was done in real-time whenever an experiment 
generating data signals was being conducted. At ot. er times the 
computer was used for off-line data processing and software develop- 
ment. Although the SORC computer and JSC science computer com- 
patibility was established as planned, there was a serious problem 
in establishing a workable interface between the JSC ground based 
data system and the JSC science computer. That delay of approximately 
3 weeks precluded an end-to-end systems checkout including the real- 
time data processing software. The consequence was a one week slip 
in the SMD III test and some software development taking place during 
the SMD III test. 

During the two day simulation not ell of the experiments were exer- 
cised, but it still became apparent that some of the planned night 
data processing could not be accomplished, but would have to be 
done post test. The primary limitation was the time required to 
transmit the full data stream (as planned) over the 9600 baud line 
in the time allocated. 
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3. 2. 2. 3 Data Display 

Data Display of the experiment data was accomplished in real-time 
as planned for the respective experiments. The display formats 
were established in conjunction with the respective P.I.'s and 
considered more than satisfactory for providing the P.I. with 
sufficient information in appropriate form to be truly interactive. 
The type and number of data display devices in the SORC was 
adequate for the SMD III test, but as for the computer there was 
no back-up equipment readily available. 

Operationally, the delays in data acquisition cited in 3. 2. 2.1 
above did cause some confusion betweer hat was displayed on the 
JSC stripchart which was hardwired to tne onboard system (certainly 
an un-real situation for a real mission) and what was being dis- 
played on the stripchart in the SORC from the lagging digital data. 

The SMD III test time-line was established to have the experiments 
run serially and the data system was structured accordingly. Such 
an arrangement may not be possible for a real mission. 

3. 2. 2. 4 Software 

The software was divided into "system" software and "applications" 
software and was developed independently along those lines with 
well defined interfaces. Each category of software was tested 
informally with its own test data generator programs. The inter- 
faces were kept simple, to a minimum and well defined. Special 
software was written as required to verify the output of the 
system software as it was developed. The application software and 
system softwa*^ were merged and tested in a loop mode at ARC to 
verify all ARC internal interfaces. 

Delays were encountered in establishing the ARC/JSC interface and 
time was inadequate for proper interface testing prior to opera- 
tional support. A one week schedule slip allowed the methodical 
checK 4t of each data format. Numerous programming errors were 
discovered and corrected within this time and the system was able 
to support full operations by the end of the week. 

Software systems generally evolve with usage. This was particularly 
true in SMD III; however, with the short time available for end-to- 
end testing a significant amount of program evolution occurred 
during normal working hours and excessive shift work for program 
development and refinement. 

3. 2. 2. 5 Communications System 

The communications system was generally grouped into two segments, 

1) the data links and 2) the voice links. 
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The 9600 baud high speed data line was routed directly from JSC 
to the SORC. To preclude potential probleros, the attendant SORC 
209A data set was positioned in che computer rack. No malfunctions 
were experienced with the equipment thus allowing the link to be 
fully utilized. Due to the limitations of the 9600 baud line, 
selective data compression was necessary, but did not compromise 
any of the experiments. 

The other data links were designed to be used in conjunction with 
the FTS phone lines with no data compression. 

In addition to the data links, the entire voice communications 
systeiu had to be installed in the SORC. The requirement was to 
supply an appropriate system which would allow the SORC to com- 
municate with JSC and also the onboard crew. Such a system was 
established, but only by expending considerable effort after the 
initial installation and then with unresolved problems that 
Impeded the real-time operations of the SORC. 


3.2. 2. 6 Slow Scan TV 

Slow scan TV equipment was supplied to the SORC and JSC by the 
Nippon Electric Company for use during the SND III test. The slow 
scan color TV was the only TV planned for and installed in the 
SORC. The TV si^al from the NEC equipment was transmitted over 
an FTS telephone line which proved to be reasonably reliable and 
sufficient for tiie use intended. Picture quality was excellent. 
Close-up pictures in support of specific experiments were not 
required nor obtained. The system could be used to obtain "snap- 
shots" but preferably not as a complete replacement to a full TV 
stream. 

Once in operation, the disc recorder proved a good way to record 
the slow scan TV pictures in view of the recording quality, the 
flexibility of operation and the recall capability. However, for 
post test storage, the images had to be transferred from the disc 
to magnetic tape. 

4.0 RECOWtNDATIONS 

4.1 JOHNSON SPACE CENTER 

1) Allow adequate time for delivery of critical hardware 
and software items. A late delivery perhaps does not 
appear to impact the test, but it telescopes the develop- 
ment schedule so severely that the personnel responsible 
are under undue strain to attempt to meet milestones. 

A certain amount of pr-'ssure is beneficial to a project, 
but when it becomes ove. bearing, productivity and 
efficiency suffer. 
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2) The use of OECNET and RSX-11N was very good for quick 
development of a large quantity of software. These 
standard, vendor-supplied systems are well documented 
and relatively free of bugs. It is recommended that 
future development of such systems fully utilize such 
cooroercial software packages. 

3) The second day before the seven day simulation one of 
the P.I.'s requested a significant software change. 

This change was made, tested and validated before the 
simulation started. Such a response is characteristic 
of a payload dedicated operation and singularly un- 
characteristic of a control center operation. This 
supports the concept of a payload specific ground based 
computer system. 

4) In operating a data system such as that for SMD III, 

or for operational use, a dedicated communications loop 
is required for data coordination. In SMD III, the 
Data Manager required closely timed coordination with 
the real-time computer operator, the data recorder 
technician, the science computer operator, and the Ames 
operators, which was extremely difficult using telephones 
and shared communications loops. 

5) Sufficient monitors should be provided such that the 
Data Manager, who is responsible to Science and to 
Flight for data operations, has a complete status 
display of the entire data system, including status of 
a remote transmission link and how far behind real-time 
the data is being transmitted. 

6) The test suggests that further consideration and study 
be given to: 

a. Increasing bandwidth capability to Ames. 

b. Simplifying experiment interfaces to the onboard 
system and providing test units for this task. 

c. Identifying and standardizing experiment onboard 
display equipment (including stripchart). 

d. Documenting data systems reliability requirements 
a..d the fidelity level required for the integration 
program. 

4.2 AMES RESEARCH CENTER 

ARC reconmendations for all future endeavors and planning, whether 
additional SMD tests or for a shuttle life sciences dedicated mission, 
are as follows: 
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1) Include a SORC in the planning as an effective operational 
entity. 

2) Complete installation and checkout of all data links 
and conmuni cations links prior to any operational use. 

3) Data link should have sufficient speed to accommodate 
pnysiological Maveform data. 

4) Define and establish better methods for the ground 
personnel (and particularly the P. I.'s) to determine 
the experiment progress. 

5) Provide backup equipment for critical data system 
components, i.e., computer main frame, certain data 
display devices, etc. 

6) AlloM sufficient time for software development and 
checkout. 

7) Exercise all experiments in end-to-end systems tests 
and/or simulations prior to test/flights. 

8) Provide remote control for onboard TV cameras and a 
full TV stream for P.I.'s. 

9) Provide software for real-time continuous waveform 
display of experiment data and for summary data displays/ 
hardcopy for P.I.'s. 

10) Computer operational checkpoint capability would be 
a plus. 

5.0 DISCUSSION 

5.1 SYSTEM DESCRIPTION 

The Spacelab Mission Demonstration III (SMD III) was designed to 
simulate the systems and concepts involved in a genuine Spacelab 
flight. Various life sciences experiments typical of those which 
might constitute a payload on a Spacelab mission were evaluated and 
selected for the simulated mission. The data requirements of these 
experiments were considered along with the proposed capabilities of 
the Spacelab data system and a low cost data system simulator was 
conceived. Figure 5-1 is a simplified block diagram of the data 
system developed for SMD III. 
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FIGURE 5-1, SMD III DATA SYSTEM BLOCK DIAGRAM 





The Onboard Data System was simulated with a single Varlan 6201. 

This system was used to acquire data from the experiments, log It 
on tape for archival purposes, and send It to the Ground Data 
Syster (GDS). The air to ground link was simulated by a hardwired 
computer to computer Interface. The GDS was likewise simulated by 
a single Varlan 6201. The GDS served as the ground telemetry sta- 
tion and the real time display driver of a Payload Operation Control 
Center (POCC). 

Due to the limited core capacity and A-to-D Inputs of the ODS, It 
was ground ruled that only a single active experiment would be down- 
linked at a time. A patch board system on board was used to select 
experiment Inputs, and the downlink configuration from the ODS was 
changed to support each experiment. 

An onboard analog system, with recording capability, was Installed 
as a backup to the digital system, and to handle high rate data. 

Due to lack of D-to-A converters for the GDS, the analog system was 
hardwired to analog displays In the POCC. 

The existing ^CDICS computer system at JSC was remotely accessed 
from the POCC and the SORC for data base storage and retrieval of 
the data library Index and test status Information. This system 
was also available to the Flight Surgeons console to provide access 
to crew medical records. 

Data Trom the GDS was fed to a PDP 11/40, used as the Science Computer 
In the POCC for temporary data storage and near- real -time processing. 
Furthermore, the Science Computer was used to drive the real-time 
data link to the SORC at Ames Research Center. 

The SORC data link terminated at another PDP 11/40 computer, which 
served as the SORC display driver, as well as for scientific processing. 

Comtp Icatlon with the SORC from the POCC and test area was also 
maintained by a slow-scan TV system, and by two voice comnunl cation 
1 1 nes . 

5.2 SYSTEM DEVELOPMENT 

A summary of the development and configuration of each system Is as 
fol 1 ows : 

5.2.1 Onbo a rd Data System (ODS) 

5. 2. 1.1 F..,)Ct1ons 

1) Simulate a limited Spacelab Remote Acquisition Unit (RAU). 

2) Provide real-time onboard parameter display and downlink 
configuration control via one CRT/keyboard terminal. 
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3) Log all digital data. 

4) Provide engineering units conversion. 

5) Interface with the G05. 

5. 2. 1.2 System Description 

The ODS digital section consisted of a vintage Varian 6201 mini- 
coroputer with 20K core memory, two magnetic tape drives, small 
drum, paper tape reader, 48 AO channels, CRT display, 3 serial I/O 
channels, and keyboard (See Figure 5-2). In the real Spacelab 
this system would consist of three flight French computers in the 
Spacelab and four flight IBM computers in the orbiter. The com- 
plete ODS was placed outside the mockup with only the CRT display 
and keyboard being onboard for crew Interaction. 

Because of the limited A-to-D channel capacity of the ODS and the 
lack of a backup ODS, a patch board system was installed. Onboard 
all analog signals were routed to a patch panel as shown in Figure 
5-3 where they went to the ODS for A-to-D conversion and 
directly to analog recorders and stripchart recorders in the science 
monitoring room. Experiments were grouped and the crew inserted 
the appropriate patch panel before running a specific experiment. 

In the real Spacelab, sufficient capability has been baselined to 
handle all channels simultaneously. 

With respect to interfacing the specific experiments to the onboard 
data system, several problems were encountered. One experiment 
(#66) required a digital sampling rate higher than the available 
equipment could handle so the ODS was bypassed to display it 
directly on stripcharts in the science monitoring area. OTR #1 
and experiment #75 used microprocessors and the serial interface 
cards could not be delivered on time and the ODS was bypassed. 

All other experiments went through the ODS. It should also be 
noted (Figure 5-3) that all experiments had local displays inde- 
pendent of the ODS. As originally implemented, the ODS was to 
provide a digital downlink of 4,000 SPS, however, this was not 
needed and was changed to 2,000 SPS continuous downlink to the GDS. 
ODS and GDS design is described in SD-SMD- 1 11-005. 

5.2.2 Ground Data System (GDS) 

5. 2. 2.1 Functions 

1) Interface with the ODS. 

2) Provide real-time parameter display and control in the 
Science Monitoring Room and on the test conductors 
console. 

3) Provide limit sensing. 
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FIGURE 5-3, SMD III ONB.ARD DATA FLOW 




4) Provide parameter printouts for any selected experiment. 

5) Interface with the Science Processing System. 

6) Provide engineering unit conversion. 

5. 2. 2. 2 System Description 

Like the ODS, the 60S consisted of a vintage Varian 620i with 20K 
core memory and assorted peripherals (see Figure 5-4). Specific 
software was written to accomplish the functions specified. Once 
the test started, an auditory alarm was added to alert the monitors 
whenever any of the cage temperatures or other selected parameters 
went out of limits. In effect, the 6DS attempted to simulate POCC 
functions normally provided by IBM 370 computers in Mission Control. 
The output of GDS was a continuous block of 4,800 words to the 
Science Processing System. 

5.2.3 Analog Data System 

5. 2. 3.1 Signal Routing 

Analog signals originating at the various spacelab experiments were 
distributed throughout the analog data system by means of an analog 
patch panel located in the Spacelab Core rack. Data from the ex- 
periments was routed to interface panels mounted underneath the 
floor sections, where a mating cable carrie' it to the analog patch 
panel. The data was passed to various poin^j within the system. 
Actual routing of signals was controlled by installing different 
patch boards in the patch panel. 

The analog data system is illustrated in block form by Figure 5-5. 

Stand=ird procedure was to route the data through a buffer amplifier 
which was associated with a particular A-to-D converter channel 
of the onboard Varian computer. Output from the buffer amplifiers 
was then passed to other equipment within the analog system. This 
arrangement kept the input impedance to the A-to-D converters con- 
stant as different analog system devices were incorporated. 

Digital information generated by the experiment was routed to the 
onboard Varian computer through a similar patch panel arrangement. 

5. 2. 3. 2 Analog System Capabilities 

As pointed out previously, all analog signals were routed through 
the analog patch panel and buffered before being sent to other 
analog devices. Each of the inputs to the 32 buffer amplifiers was 
physically wired to the input of an A-to-D converter within the 
onboard Varian computer. The buffers were differential input 
amplifiers having a closed loop input impedance of four megohms. 
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figure 5-4, SMD III GROUND DATA SYSTEM BLOCK DIAGRAM 
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or 1 meg. when used single end‘»d. Frequency response of the buffer 
aroplifers was DC to 6 Khz. 

Two FR 2000 magnetic tape recorders operating at 1 7/8 IPS were 
used to record analog data from the experiments. IRIG B time code 
was placed on channel 14 of each recorder. 

Two eight channel stripchart recorders (Gould Brush Recorders) 
were located in the POCC to provide the P.I. with a hardcopy of 
his analog data. IRIG B Slow code at 10 seconds per frame was 
placed on marker channel B of each recorder. A switch selectable 
experimenter supplied analog differentiator could be inserted on 
channel 5 of recorder #1 or #2 at the discretion of the Data 
Manager. 

Additional means of viewing analog data by the P.I. was provided 
by way of a Tektronix R556 dual beam oscilloscope mounted in the 
PI /PE console. Two 16 position rotary switches gave the P.I. the 
option of placing data appearing on the strip chart recorde>" on 
either, or both channels of the oscilloscope. Two experimenter 
supplied audio monitors were mounted in the PI/PE console. Selection 
of the monitors was by means of a 3-position rotary switch located 
under the oscilloscope. 

A 6-channel stripchart recorder located on board the spacelab 
allowed the crew to display and make hard copies of analog data 
from the experiments. 

5.2.4 POCC Science Processing System (Science Computer) 

5.2.4. 1 Functions 

The major functions of the computer were: 

1) Demultiplex the downlink buffer. 

2) Distribute the demultiplexed data to experiment specific 
tasks. 

3) Perform rudimentary processing. 

4) Store the data in experiment specific files. 

5) Send data to the Science Operations Remote Center (SORC) 
at Ames Research Center. 

6) Plot selected data values for investigators. 

5.2.^ 2 Hardware Description 

The science computer was a PDP 11/40 with the following features: 
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1) 112 K memory (16 K DEC core and 96 K semiconductor) 

2) Decwriter console printer 

3) 2 Tektronix graphics display units 

4) LV 11 electrostatic line printer 

5) TMB-11 tape drive 

6) Floating point instruction set 

7) 4 RK05 cartridge disk drives 

8) 2 RX-11 flexible disk drives 

The interface to the Varian 6201 ground system was accomplished using 
a Digital Equipment Corporation supplied DR-llB parallel gital 
interface. The cable wiring was performed by Ford Aer e and 
Communications personnel. The interface to the SORC c er at 
Ames was performed using DECNET, Digital Equipment Co»v on's 
network system. The hardware on the science computer Vv-. « MOB 
Systems supplied DU-11 synchronous line adapter. This was inter- 
faced in turn to a Bell 209 9600 modem to the SORC computer at Ames. 

5.2. 4. 3 Operating System Descriptiort 

The POP 11/40 science computer was operated under the DEC supplied 
RSX-llM operating system, version 2.0. This multitasking real time 
system provided all the executive and supervisory services to run 
the multiple tasks required to Support SMD III in the science 
computer. The system supported both assembly language (MACRO-11) 
and FORTRAN programs and provided a consistent I/O structure. 

The network portion of the system was supported by DEC'S DECNET 
version 1.1. This software package running under RSX-llM provided 
the data transfer functions and remote program control functions 
required to fully support the SORC. Particularly effective was 
the DECNET concept of multi leaved data streams whereby several 
logical links can be supported over a single physical link. This 
allowed the applications software to be experiment specific and 
relatively independent of other programs in the system. DECNET 
handled all line protocol and maintained statistics on the line 
and link. DECNET also proved to be valuable as an operating tool, 
allowing hardcopy communication between the SORC and science com- 
puter operators. Typewritten messag 2 s, as well as files and examples, 
could be sent between the two centers via DECNET. This was especially 
useful for synchronization and query when the voice loops and tele- 
phones were all bur.y. 


(21) 



The interface to the Varian via the DR-llB posed an initial problem 
in that the DR-llB is not supported as a standard device under 
RSX-llM. A user written driver had to be developed and incorporated 
into the operating system to allow convenient and consistent soft- 
ware access to the device. Under version 2.0 of RSX-llM, all 
device drivers must be developed and loaded at SYSGEN time. This 
causes considerable problems in debugging a new driver. Under 
version 3.0 loadable driver support is included. Therefore, the 
DR-llB driver was developed under version 3.0 and then migrated 
back to version 2.0 for the operational system. For further design 
details, refer to the repor*. Science Computer Software System for 
SMD III. 

5.2.5 High Speed Data Link 

The SORC computer was connected to the JSC Science computer by a 
high speed data link (9600 baud conditioned telephone line from 
JSC to the SORC through 209A-L1 data sets). The use of the 9600 
baud telephone line limited the amount of data that could be sent 
to the SuRC to approximately 400 words per second. That limitation 
ne <!ssitated the formation of various strategies and the writing of 
appropriate software at both JSC and ARC for getting sufficient data 
to the SORC during the conduct of an experiment. In addition to 
the 9600 baud data line, several FTS telephone circuits were 
utilized for voice coordination and separate transmission of data 
signals such as X50 audio blood flow. 

In the early planning of the SORC and the data system, it was 
thought that for redundancy two 9600 baud lines may be needed. 
However, based on the reliability of the first link during the 
first week of operation, it was decided in the interest of economy 
to have only one 9600 baud line for the SMD III test. The sound- 
nc;ss of that decision was later confirmed by the fact that the 
high speed data link went down only once during the SORC operations. 
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5.2.6 PCCC Slow Scan TV Systew 


The POCC slOM scan TV system was required to transmit color or 
black and idiite pictures from the Spacelab to the SORC and to 
receive black and white pictures from the SORC for display in 
the POCC. 

The system was built around equipment furnished by Nippon Electric 
Company (NEC) and included the following 

1) NEC equipment consisting of a Model DFP-751 Color Freeze- 
Picture Transmission System, an HPP-7100DC Poiver Supply, 
an HPB-6782 Remote Control Console, and appropriate 
connecting cables. 

2} Bell Telephone Data Set 2088 

3‘ A black and white monitor for the live TV feed to the 
system. 

4) A color monitor reflecting the contents of the system 
memory, i.e., the picture being sent or received. 

The POCC slow scan TV system had the capability to both send and 
receive via a non-conditioned telephone line. Inputs to be sent 
were taken from a TV feed line from the TV officer's console in 
the Test Control Area. Any downlink output from the mockup could 
be switched onto this line, with or without a superimposed digital 
clodc image. The TV console was also connected to the JSC TV 
control system, allowing the receipt of previously recorded TV, 
test patterns, and commerical TV. 

A feed from the slow scan system back to the TV console allowed 
incoming pictures to be put on any of the monitors in the Test 
Control Area or the POCC, or to be routed to JSC TV control. 
Initial attempts were made to videotape the incoming pictures in 
the TV control area, with only limited success. It was discovered 
that the transmission included only a single field, with no inter- 
lacing, which was incompatible with a standard video tape recorder 
(VTR). An interlaced signal could be produced by pre-recording on 
a disc and replaying the regenerated signal to the VTR, as was 
done on TV fro»n earlier space missions. There was insufficient 
need for recording transmissions to the POCC, however, to justify 
the additional equipment and operators required. 
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5.2.7 SORC Data System 


“The primary purpose of the ARC Science Operations Remote Center 
is to receive data generated by the respective experiments and to 
process and display those data in such a manner as to allow real- 
time evaluations and decisions concerning those experiments." 

(Excerpt from SORC General Policy). The development of the real- 
time data system and the complimentary connuni cations system was 
directed toward the attainment of that capability. 

It was recognized very early in the planning of tf« SORC that the 
computer system would be a long lead item. At that time, the exact 
experiment requirements were not known. Consequently, the computer 
system was designed to have a certain amount of inherent flexi- 
bility and the final system (as described below) was reasonably 
close to that planned for the SORC. 

A POP 1140 computer formed the nucleus of the SORC real-time 
system. Peripheral equipment required for SORC operations included 
expanded memory (up to 12^), two RK05 Disc drives, two Kennedy 
9000 9 track tape drives, two Omron Video Displays, a VT-11 CRT 
display, a Versatek Plotter, a custom built digital-to-analog 
converter (DAC), an eight channel brush stripchart recorder, a 
teletype and a DQ-11 communication device. 

The computer was moved to the SORC in early February. Its basic 
configuration at that time consisted of 32K of msmory, two disc 
drives, the VT-11 and the Versatek Plotter. Installation of the 
RSX-11N Version 2 operating system began at that time to allow 
multiple user access to che machine during software development. 

The first priority was to expand the memory from 32K to 96K using 
the DEC Memory Management System and Plessey memory cards. Slow 
delivery from Plessey in^eded progress in this area for approxi- 
mately one week but, once received, the added memory caoability was 
rapidly installed and checked out. Addition of the tw. ''iiron displays 
from JSC allowed software development to proceed as planned. The 
installation and check out of the DAC and st.'ipchart recorders 
completed the hardware configuration necessary for development of 
the science applications software. 

SORC system software development was somewhat hampered by late 
delivery of the Bell 209 Modem (used for tie-in to the 9600 baud 
line) and the power racks for the two Kennedy 9000 tape drives. 

Again, once the hardware was received, it was rapidly installed 
and checked out without difficulty. 
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In general, the late delivery on sone hankare iteas did not 
seriously delay software development. There always existed a 
sufficient quantity of parallel software development tasks to 
which the progranning manpower could be diverted until hardware 
items were installed. 

During software development, the SCRC computer hardware worked 
flawlessly. Hardware down time from equipment failure was negli- 
gible. During Phase Training, the two-day simulation and SND III 
itself, hardware failures on almost each peripheral device occurred 
at one time or another. The failures were in all cases fixed within 
six hours of their detection and, only in the case of the tape 
drive failure, was the entire system forced to be shut down. The 
most frequently occurring problems were caused by nuisance failures 
in the stripchart recorder - pens clogging, paper alignment, amp- 
lifiers and pen drivers with intermittent failures, etc. Eventually, 
the original recorder was swapped out with a newer model from the 
ARC bedrest facility. One Omron display failed at the end of the 
two day simulation. It was hand carried to the factory for service 
(replacement of a timing PC board) and returned the same day. The 
Versatek printer/plotter stopped functioning at one point during the 
seven day simulation. A service engineer from Versatek disassembled, 
checked and reassembled the unit. No hardware problems were found; 
the ixiit began ftxtctioning again and continued to do so throughout 
the remainder of the simulation. 

The only hardware failure which impacted the SORC occurred during 
the second day of the seven day test when the primary tape drive 
failed to log the incoming data on tape. The system was shut down 
while inspection of the tape drive progressed through the night. 

It was finally ascertained that a cold solder joint in a power 
regulator was the culprit. After readjusting the bridge balance 
on the regulator output the tape worked properly for the remainder 
of ttie test. 

The impact of this failure was a loss of approximately six hours 
of background data plus the uncertainty of the quality of the data 
logged on the tape prior to detection of the failure. 

The actual hardware configuration used in SND III was the full 
realization of the system planned three months earlier. Trade-off 
studies performed in the planning stage minimized the number of 
output displays to save costs. The switchable two page display 
capability of each Omron allowed four output formats to be displayed 
by tile viewer without significant impact on the system sofbvare or 
mass storage resources. The VT-11 found more use than originally 
planned by displaying the Experiment 76 Pod data during background 
data collection periods as opposed to only durii.^ LBNP runs. In 
retrospect, an additional numerical display would have been useful, 
but not necessary, for display of selected experiment specific 
parameters in experiments 5, 13, 50 and 57. For the most part, 
however, graphical presentation of the data was adequate for the 
experimenter's real-time assessment of the data. 
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5.2. 7.1 SORC Voice Conminicatlons Link 

Initial planning for the SORC included the folloMing voice comouni- 
cations lines: 

1) Science Monitor; JSC com loop 

2} Air to Ground; JSC com loop 

3) Video link; dedicated FTS line 

4) Audio blood flow and data fax; dedicated FTS line 

5) Science coordination; non-dedicated FTS line 

6) Test coordination; non-dedicated FTS line 

7) Data coordination; business line 

8) Three each telephone lines with FTS and 9 level capability 

In order for ^ SORC tc function properly it was anticipated that 
three positions within the SORC would require speakers, headsets 
and push to talk microphones. The final SORC comuni cations system 
included the above cited lines, but wicn certain attendant problems. 
The problems were identified at an early stage, but were never 
resoWed by the ARC Comuni cations Rracch or the telephone company 
leaving the SORC with a sub-standard and deficient system. Problems 
inherent in the system included, but we.'e not limited to; a) the 
speaker at each of the three stations was wired to only one com 
loop with no capability to switch to the other com loop, b) the 
volume of the sound produced by the headsets was too low to be of 
value except possibly in a quiet room, c) the push-to-talk microphones 
did not switch out the adjacent speaker in the talk mode, resulting 
in a bcrious amount of feed back. Such problems presented opera- 
tional difficulties within the SORC and maybe to a lesser degree, in 
the POCC as well. 

5.2. 7.2 SORC Real-Time Data Processing 

The real-time data processing software utilized in the SORC was 
developed by two contractors. Technolog}' Incorporated and Cybemex. 
Technology Incorporated was responsible for the overall system 
specification and all science application, test data generator, 
display, hardcopy and system status software development. Cybemex 
was responsible for the overall hardware integration and maintenance, 
tne installation of the operating system (RSX-llM version 2), the 
data link software (DECNET), hardware drivers and the data logging 
software. 

The interface between the JSC and *\RC software was formally con- 
trolled by the "JSC Science Computer to ARC Science Operations 
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Remote Computer Interface Control Document for SMD III". This 
doament specified the format and Internal structure of each of 
17 possible data record types, their frequency of transmission and 
the conmunicating task names (required by DECNET). The basic data 
link design concept was to accumulate data at JSC in records 
specific for each type of experimental data then transmit these 
records via (^CNET to corresponding tasks in the ARC computer. 

CECNET provides for transmission error detection, automatic frame 
re- transmission and status code logic in both the sending and 
receiving tasks. The inherent capabilities of DECNET assured error 
free transmission of the data frames; however, in doing so, the 
maximum transmission rate on a 9600 baud line was limited to 400 
words per second. This constraint prevented the direct transmission 
of the 2000 word frames generated by the onboard computer, required 
the use of oata compression at JSC and impacted the real-time 
reconstruction of physiological waveforms as will be discussed 
below. Development of alternate data transmission protocols cor* 
patible with RSX-llM was felt to be too time consuming and too 
risky in view of the proximity of the fixed scheou..^ milestones 
before us. DECNET did prove to be highly reliable during operations 
and once the system and the users became accustomed to its limita- 
tions, the decision to use it was vindicated. 

Selection of the RSX-llM Version 2 operating system was based on 
the need for expanded multi-user, multi-task capabilities over RT-11. 
Some debate occurred on whether or not to wait for Version 3 to be 
released since some problems were known to exist in Version 2, 
particularly in the areas of VT-11 displays, tape handling and 
checkpointing. A history of one month slips by DEC in the release 
date cast doubt on the credibility of the proposed release date at 
that time. The decision was made to live with Version 2 and to 
design the software accordingly. As it turned out, just about the 
time the Version 2 display problems and the tape handling problems 
were overcome by software workarounds. Version 3 was released. The 
decision remained to stay with Version 2, since we were well into 
the development of system software by that time. System crashes 
and the inoperability of task checkpointing did cause consternation 
downstream during final software system integration. Whether or 
not Version 3 would have avoided these problems is not known; 
however, it is quite likely that a switchover to Version 3 upon its 
release would have impacted the software development schedule by 
one to two weeks. 

Utility software developed on the system primarily centered around 
output devices. The DAC driver was a modified version of the Lab 
Peripheral System (LPS) driver. It allowed use of the standard 
A-to-D Fortran calls developed for the LPS and its use was trans- 
parent to the calling task. A macro called SCHART was developed to 
simplify and standardize the interface between the science applica- 
tions software and the DAC driver. This macro underwent considerable 
development to decrease its size and improve its speed. Standard 
macros were developed for utilizing the Omron's and an entire graphics 
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package (GRAFIX) was developed to support the VT-11 CRT displays. 

The latter was necessary since the RSM-llM Memory Management System 
which utilizes a virtual memory is incompatible with the fixed core 
software of the VT-11. Also as part of the utility software, a 
graphics text editor (VTEDIT) was developed, a much needed improve- 
ment over EOI, the DEC text editor. With both editors available 
on the systan simultaneous program development by several users was 
made possible. 

After development of the operating system and the above mentioned 
u*^*lities, work started on the SMD III peculiar software. The 
sj.Lera design was based on an "hourglass" configuration; that is, 

17 input paths existed between the 17 record generating tasks at 
JSC and the 17 corresponding receiver tasks at ARC. All the receiv- 
ing tasks reported receipt of data to a single controlling executive 
task which logged the data on tape and enabled processing of the 
data in one of 12 application tasks. 

This concept was utilized to isolate the ARC Computer from the 
control of the JSC computer at some central point. This was neces- 
sary since DECNET, when used in the task-to-task mode, initiates 
receiver tasks in the downstream computer as required. 

In order to maintain local control of the number of tasks running 
while at the same time allowing the system to be as automated as 
possible, the receiver tasks, under direct control of the JSC com- 
puter, were designed to have minimal impact on the ARC computer. 

Their functions were to direct the incoming data frame to a pre- 
allocated portion of a global common, COMBUF; to inform the executive 
via an event flag that new data had arrived and, upon receipt of 
processing complete signals from the executive logger and the 
corresponding science applications program, request the next frame 
of data from the JSC computer. Note that using this technique no 
data would be lost at ARC. Delays in ARC logging or processing 
resulted in "backing-up" the data on the JSC spool since the receiver 
would not request new data until the current data had been con^)letely 
processed. 

Time and core were saved by using a global common buffer for storage 
of the incoming data. This buffer and the set of event flags indi- 
cating processing status formed the m?in interface between the "system" 
software and the "science applications" software. Although infor- 
mally controlled once it was defined it was strictly adhered to and 
remained stable throughout the software development process. Early 
definition of this and the JSC/ARC interface allowed the parallel 
development of the system and the applications software. 

As described below, the applications software was developed com- 
pletely independent of the system software; this included separate 
discs, separate working hours for the programmers and separate test 
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data for program testing. It was not until the software integra- 
tion phase of the project that the programs were played together. 
This points out the need for simple, clean and well defined inter- 
faces between generic types of software. 

Integration of the system and application software went very 
smoothly on an experiment-to-experiment basis. Total system inte- 
gration, however, uncovered run time and core allocation problems. 

A second generation logging executive and independent tape writing 
task were generated to improve overall run time. The SCHART macro 
was rewritten to reduce its size and run time. With the new 
improved programs the system was operational and ready for end-to- 
end checkout with JSC. 

By the time both the JSC and ARC systems were ready for end-to-end 
tests the SORC was being called upon to support Phase Training. 
Going directly to live experiment data undercovered problems in 
the JSC/ ARC interface in which it was difficult to identify the 
source since all the links in the end-to-end data system were 
involved. Little progress was made until Project management placed 
a one-week hold on the schedule to allow a checkout of the data 
system. 

The most fruitful checkout was the snd-to-end voltage test whereby 
a known constant voltage was applied to the onboard patch panel 
pins and sampled according to each possible configuration number. 

A review of the digital values reaching the SORC quickly identified 
problems in both the transmitting and receiving software. Most 
problems involved the miscalculation of array pointers and were 
readily corrected. A digital tape made from the GDS allowed the 
test to be replayed until satisfactory results were obtained. 

A User Demonstration Test was conducted with each P.I. before the 
Project schedule was resumed. In this test taped data was played 
through the Science Computer at JSC and transmitted to the ARC 
computer where all data processing functions were performed and 
verified by the P.I. The system was at this point ready to support 
operations. 

5.2. 7. 3 SORC Science Application Software 

The primary objective of the SORC science application software was 
to provide the P.I.'s with a real-time display of their data in a 
manner which would facilitate the evaluation of the quality of the 
data signals being collected and the identification of major trends 
in the data. In general, this meant the reconstruction of analog 
waveforms for stripchart displays and the production of sunmary 
plots and listings on various output devices. 
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Seventeen programs were originally identified; one corresponding 
to each of the possible data formats sent from JSC. Since 
similar functions were to be performed in each of them (data block 
receipt, time decoding, decalibration, display outputs, etc.), 
a skeleton master program, XXXGEN, was written first as a pro- 
granning standard. Use of global text editing techniques allowed 
the rapid production of 17 individualized rough cut programs from 
XXXGEN. Common functions such as time word decoding and strip- 
chart output displays were identified as Fortran callable macros. 

Early versions of the application programs provided their own test 
data generation code as a debug option in the compilations. This 
decoupled the programs from the development of system software and 
allowed an early start on the decommutation, decalibration and 
display portions of the application programs. As system software 
became available; namely, DECNET, the executive and the individual 
receivers, the test data subroutines were broken out of the programs 
and rewritten as independent programs utilizing DECNET to transmit 
the test data, thereby exercising the total ARC data flow paths. 

The outputs from the application programs are sunmarized in the 
Data Products and the SORC Display tables of Para. 5.3.4. 

On two of the high data acquisition rate experiments, X76 and X50, 
the maximum transmission line data rate of 400 sps required the 
experimenters to choose .between greatly degraded waveform recon- 
struction at a slow sampling rate or "snapshots" of data transmitted 
in slower-than-ieal time (i.e. , 15 second samples sent over 45 
seconds). The P.I.'s opted for the "snapshot" technique. This 
meant that only 25% of the acquired data would end up a* ARC in 
real-time. The original plan called for transmitting la0% of each 
day's recorded data during the night for both of these experiments. 
With a 4 to 1 time expansion it would have taken two hours of trans- 
mission for each 30 minutes of data collected. 

This technique was tried for the first night of the simulation. 

Since there was not enough manpower to staff the SORC computer on 
a 24 hour basis, the makeup data transmission was tried in an un- 
manned mode. Approximately four to five hours of transmitted data 
could be collected this way, but invariably a tape switchover, a pro- 
gram abort or an unknown error condition would cause the process 
to halt. The 24 hour real-time background data would be spooled 
at JSC so none of it was lost, but by the time the system was 
restarted in the morning, live data collection was ready to begin 
and transmission of the makeup data was held off until the following 
night. At this rate the makeup data soon became several days back- 
logged and the entire concept was re-evaluated and dropped since 
the real-time data acquired during the day was sufficient for P.I.'s 
experiment evaluation. The alternate chosen was to send the makeup 
data tapes after the mission. 
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5,2. 7.4 SORC Slow Scan TV System 


A complete slow scan TV system for the SORC was designed around 
the equipment supplied by Nippon Electric Company (NEC). In 
general, the SORC (as was planned) had the capability to receive 
color pictures through the slow scan system and display those 
pictures on various color TV monitors; to transmit over the slow 
scan system black and white pictures; to store selected received 
and transmitted pictures and on demand retrieve and display any 
one of the stored pictures on the SORC monitors. 

The final slow scan TV system in the SORC included the following: 

1) NEC equipment consisting of a model DFP-751 Color 
Freeze-Picture Transmission System, an HPP-7100 DC 
Power Supply, an HPB-6782 Remote Control Console and 
appropriate connecting cables. 

2) TV monitors for signals into and out of NEC equipment. 

3) TV color monitor for displaying images from the NEC 
equipment. 

4) TV disc recorder - Data Disc model 3106 - which had the 
capability of storing up to 200 images and playing l>ack 
two pictures simultaneously (one from a fixed head and 
one from a moving head). 

5) TV color monitors for images from disc recorder. 

6) Two black and white TV cameras; one on a tripod with a 
zoom lens and the other mounted vertically over a 
lighted table for documents, drawings, graphs, etc. 

7) Equipment to send received or stored TV images to 
Stanford University via a microwave link and to received 
images from Stanford which could be sent to JSC via the 
slow scan TV system. 

The slow scan TV system was used on a daily basis in conjunction 
with the preparation for the SMD III test including phase training 
and the two day simulation. Commencing on April 5, 1977, the TV 
system was operated continuously throughout the day. During the 
two day simulation the system in the SORC was operated continuously 
for nearly 40 hours. During the SMD III test the system was 
operated continuously throughout the seven day test - approximately 
160 hours. Total time that the slow scan TV system was operated in 
the SORC was estimated at nearly 400 hours. 

One major problem that required a considerable effort to overcome 
was getting the SORC video disc recorder to sync, on the signal 
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from the NEC equipment. JSC had similar problems with their video 
tape recorder and never did solve the problem. The solution used 
for the SORC was to feed the sync, pulse from the NEC equipment 
Into two sync, pulse generators which produced adequate sync, pulses 
for the disc recorder to sync. up. Even so» when the onboard hand 
held camera was used, the sync, pulse was of such poor quality that 
It could not be recognized and therefore no recordings could rou- 
tinely be made of the pictures from the onboard hand held camera. 

5.2.8 MEDICS Storage and Retrieval System 

5. 2. 8.1 Functions 

1) Provide daily experiment status reports locally. 

2) Provide remote experiment status information to Ames. 

3) Provide Crew Medical Information to Flight Surgeons. 

4) Provide access to the Life Sciences Library index 
for real-time cataloging of data. 

5. 2. 8. 2 System Description 

This system consisted of a remotely located timeshared minicomputer 
system (Varian 73) operationally used at JSC for storage and retrieval 
functions. Terminals were located in the POCC, in the flight medicine 
office, and at the Ames SORC. The system is forms oriented so that 
specific forms were developed for SMD III status! ng, manually entered, 
and selectively retrieved at any of the interactive terminals. In 
Spacelab, this system simulated a management tracking system. 
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5.3 

5.3.1 Onboard Crew Displays anJ Operations 

5. 3. 1.1 Crew Displays 

In addition to the individual experiment displays, the data syscem 
provided other common usage displays. 

The six-channel stripchart recorder was used to display and record 
real-time analog data. Originally experiment supplied for X58, it 
became common usage equipment for XI 3, X50, and X76 as well. Although 
time was required for setup, and maintenance of the ink-fed stylii 
presented problems, the crew felt that this type instrument, or 
other analog device, was required to view analog data and notice trends 
that would not be apparent on a digital display. One failure occurred 
on day 4 when ink failed to feed to any of the pens. The unit was 
passed out and replaced with a spare unit. The failure was traced to 
a metal shaving shorting the control for the ink feed solenoid. 

The onboard ODS terminal contained a CRT display which presented 
experiment data, updated every one second, in formats corresponding 
to the experiment configuration as described in SD-SMD-III-002. 

In order to satisfy a crew request for an environmental display on 
board after the system had been configured, a second CRT was added, 
driven by the 60S, paralleling the environmental display on the 
Data Manager, Flight Director, and Payload Officer's console, since 
this display output was already available. 

5. 3. 1.2 Crew Operations 

Experiment selection and downlink data configuration ^ere all 
selectable by the flight crew. 

One of nine patch panels was inserted by the crew, depending on the 
experiment to be run. Patch board selection configured the onboard 
stripchart recorder, the onboard analog recorders, and the downlink 
analog system, and selected the parameters available to the ODS for 
downlink. Parameters and configurations for each patch panel are 
given in document SD-SMD-III-001. No problems were reported in 
operation of the patch panel system. 

The crewman entered a coded configuration number for each experiment 
or for standby operation from the onboard terminal keyboard of the 
ODS. This configuration number configured the ODS downlink, and 
also caused the ODS to automatically display the selected experiment 
data on the onboard CRT in accordance w th SD-SMD-III-002. The ODS 
output to the CRT each second was carried on the same half duplex 
line as the input from the keyboard. This caused some operational 
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difficulties, for if a character wu entered in the keyboard when 
it was not being scanned, the computer might red eve part or none 
of the character. Attention was required to the CRT feedback while 
entering commands to verify that each character was recieved properly. 

A push button was provided on the data rack to start recorders. Use 
of this button by the crew signalled the analog recorder operator 
that the experiment was ready to take data. Use of this system was 
generally unsatisfactory, in that the crew often overlooked this 
step during the pressure of the experiment setup. 

Other comments by the crew concerned the single experiment capability 
of the system, and the need for data reduction and storage provisions. 
The fact that the system could handle only one active experiment at 
a time proved to be a constraint on scheduling, and occasionally a 
limitation on crew activity, where a crewman had to wait to perform 
an experiment while another completed an experiment in progress. 

The crew also felt that both time and space should be allowed for 
data reduction and analysis, ard that dedicated storage should be 
provided for data products and supplies. 

5.3.2 Onboard Data Recording and Downlink 

Although intended to simulate Spacelab/Orbiter systems, the "onboard" 
recorders were located outside the mockup in the Test Control Area and 
attended by ground personnel. Figure 5-6 shows the location of the 
data system equipment in the mockup and the Test Control Area and 
Figure 5-7 is a photograph of the Test Control Area in operational 
configuration. For purposes of the simulation, no data was given to 
the Data Winager or P.I. during Loss of Signal (LOS) periods, and data 
and tape management functions of the Data Manager with the operators 
were conducted only during Acquisition of Signal (AOS). 

5. 3. 2.1 Analog Data 

One or both of the two 14-track analog data recorders were operated 
as required for the number of parameters. Track assignments were 
controlled by the onboard patch panel as described in SD-SMD-III-001 . 

The recorders were only operated during experiments generating analog 
data. Operating at 3 3/4 IPS, approximately three hours of uninter- 
rupted recording was available. The recorders were operated by the 
Data Technician (DataTech) position, which war staffed by Northrop 
Services, Inc. personnel on a 24 hour, three shift basis. The Data Tech 
also operated voice recorders and performed facility maintenance in 
support of the Facilities Engineer, but was responsible to the Data 
Minager for data recorder operation. 

Data Recorder #2 exhibited mechanical difficulties during the two 
day simulation, and some parameters of X76 were lost. (Data was 
logged on the digital system and recovered.) The recorder was 
repaired by Ainpex, and although problems continued, virtually no 
data was missed during the seven day test. 

In operation of the analog system, it was found that we could not 
reliably depend on the crew signal for data take start. Close 
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■onitoring and anticipation of LOS periods Mere required by the 
Data Nanager and Data Tech to assure that recorders Mere running 
(hiring data output. 

Analog dounlink was by hardline to tte POCC «id was Interrupted by 
a switch actuated by the Siau1at1(m Supervisor (SIH SUP) during 
LOS periods. Each of the 16 analog lines to the POCC corresponded 
to a stripchart recorder channel. Charnel assignments were estab- 
lished by the patch panel in accordance with SD-SND-III-001. 

S.3.2.2 Digital Data 

The ODS formatted the digital downlink in ac<»)rdance with SD-SHD- 
III-006 based on the patch p-*ne1 Installed and the configuration 
selected by the crew. The downlink was hardwired to the CDS in 
the POCC. Input from the LOS switch actuated by SIN SUP set a bit 
in the downlink. The GDS recognized the bit and did not decode the 
downlink for real-time POCC display during LOS. The downlinked 
data continued to be transmitted to the Science Computer wd to 
Ames, where it was not displayed during LOS. 

Continuous digital tape logging was maintained of all data, placed 
on the downlink, using dual tape drives with automatic toggle at the 
end of the tape. Tape changes were required about every 50-55 minutes. 
This system was operated on a 24-hour, three shift basis by Ford 
Aerospace personnel, who also monitored the GDS in the POCC. 

Only one failure occurred during the test on day 4 when the ODS 
drum memory, tdiich had exhibited problems earlier, failed to func- 
tion when a new configuration was called. The program was reloaded 
to a new location on the drum by the operator and the system was 
restarted. A total of approximately 20 minutes of background and 
housekeeping data was lost. If the system had not recovered, a 
backup technique was available. Prior to the test, a set of tapes 
was prepared for both the ODS and GDS whereby each experiment con- 
figuration <x)u1d be loaded manually by the operator. 

An additional operating problem was the lack of communication 
betaieen the ODS operator and the Data Nanager. ITie only headset 
jack of the ODS operator was controlled from an unrelated, remote 
system console where the operators did not monitor the facilities 
coordination loop. 

5.3.3 POCC Displays and Operations 

Operation of the POCC was the responsibility of the Payload Science 
Nanager, who controlled experiment operations, flight crew inter- 
faces, P.I. coordination, and provided the management interface. 

The Data Nanager was responsible to the Payload Science Nanager 
for tie functional operation of the POCC, including data acquisition, 
processing and transmission, data recording, data storage, display 
configuration, slow-scan TV operation, coordination with TV Con- 
troller and with Facilities Engineer, and interfacing with communica- 
tions and telephone activities. 
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The Data Manager console position was staffed by Martin Marietta 
personnel on a two shift, 24 hour basis. Supporting this position 
were the OOS/GOS Operator, staffed by Ford Aerospace three-shift 
24 hours; Science Cooputer Operator, staffed by Technology Inc., 
two-shift, 16 hours; and Librarian/MEDICS Operator, staffed by 
Kentron Hawaii, two-shift, 16 hours. 

Figure 5-8 provides a floor layout the POCC and Figure 5-9 shows 
the POCC in operational configuration. The GDS and the Science 
computer are against the far wall, with the line printer to the 
left. The next row back contains the Data Manager console on the 
left and the PI/PE console on the right. The back row contains 
the Science Manager console and the table used by the ARC activities 
coordinator. 

Operation of the POCC was in accordance with AOS/LOS rules, with 
data, TV, and voice communication from the Spacelab being shut off 
by the AOS/LOS switch on the SIN SUP console. Digital data continued 
to be received, processed, and transmitted to ARC, but displays 
were inhibited. 

5. 3. 3.1 Analog Data 

The primary display of analog data was on two 8-channe1 stripchart 
recorders, shown between the PI console and the Data Manager console 
in Figures 5-8 and 5-9. Data outputs on the 16 lines were 
configured by the patch panel installed by the crew as defined in 
SD-SND-III-(rai . Initial set up of the recorders was by the Data 
Manager, but the P.I. could set up and operate the recorders at his 
option. Each recorder had one channel which could be switched to 
route data through a differentiator prior to display, for an X76 
experiment specific requirement. Some confusion arose from use 
of this switch, since the differentiator had to be switched out for 
other experiments. In between prime experiment runs, the stripchart 
recorde<^s continued to run at a slow speed to provide a record of 
the X7u pod monkeys' physiological parameters. The only mechanical 
difficulty with the recorders was a bent frame on one recorder which 
occasionally caused the paper not to track properly. 

Closer examination capability of any parameter wfs provided by a 
dual beam oscilloscope on the PI console. Either beam could be 
switched to any of the 16 analog channels. 

Audio outputs, cell firing from X66 and doppler blood flow from X50, 
were routed to the PI console. Normally, the PI used a headset to 
listen, but the signals could be switched to a speaker. An acoustic 
coupler ras used to transmit the doppler audio to ARC via dialup FTS 
telephone line. 

5. 3. 3. 2 Real-Time Digital Data ' 

The GDS received data downlinked from the ODS, demultiplexed and 
translated the data, applied engineering unit conversion, and 
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drove the digital displays. Displays were updated once per 
second, and were controlled by a keyboard on the Data Manager 
console. Only two display formats could be used at any time, due 
to hardware availability. 

The first display was a fixed configuration and contained OOS/GOS 
system status Information for the use of the Data Manager. Due 
to the format limitations, this display was also designed to Include 
spacecraft and holding facility environmental and housekeeping data. 
CRT's containing this display were made available to the Test Direc- 
tor and Payload Officer's console In the Test Control Area, In 
order that they could monitor tne environment In the Spacelab. A 
late request by the crew for environmental data, which could not 
be handled with the ODS, resulted In another CRT carrying this 
display being Installed onboard. 

The second display was callable from the Data Manager's Keyboard 
and was experiment specific. Besides the specific experiment 
parameters, each format contained “background" data from X76, due 
to the requirement for continuous monitoring of the pod monkeys. 

This display was provided on the Data Manager, PI/PE, and Science 
Manager consoles. During the test, an additional monitor paral- 
leling the console displays was added In the ARC ready room across 
the hall from the POCC. Formats for the digital displays are shown 
In document SD-SHD-I 11-002. 

A line printer was also available on call from the Data Manager's 
Keyboard. The line printer updated once per second with the same 
parameters available on the CRT displays. Experiment specific 
formats plus an environmental format were provided as called for 
by document SD-SMD-III-002. Primary use of the line printer was 
to record X76 data during active Lower Body Negative Pressure runs 
and to collect environmental data during the night for personnel 
monitoring the holding facilities. 

Prior to the test, a feature was added to the ODS and GDS software 
which allowed a display or printout to be called either In engineering 
units with calibrations applied, or in raw voltages. This feature 
was used extensively both before and during the test for trouble- 
shooting, sensor calibration, and calibration software checks. 

Both the ODS and GDS provided limit sensing on critical environmental 
and physiological parameters for the holding facilities and the X76 
raoneky pods, with an asterisk as a visual Indication on the CRT 
displays. Just prior to the test, an audible alarm was added to 
the GDS with enable/disable capability from the console. This alarm 
was quite useful, particularly on the night shifts when console 
operators had other duties. Due to a peculiar set of circumstances, 
however, an alarm was missed on day 5 of the test. The monkey pod 
air flow, one of the limit sensed parameters, had to be shut down 
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during an active X76 run due to instrumentation interference by 
the air floMneter. The auaibie alarm, therefore, was disabled 
during an active X76 run to prevent a continuous alarm signal. 

This condition existed on day 5 when the Simulation Supervisor 
generated a simulation problem of a 400 Hz power failure in the 
Spacelab. Loss of 400 Hz shuts off the air circulation system in 
one of the animal holding facilities, which generates an alarm. 

The POCC was supporting the X76 run and a simultaneous X66 run. 
and the visual indication was not noticed for almost an hour. 

Even with the audible alarm off. the delay would not have occurred 
had this been a real problem rather than a simulation. Displays 
had been furnished to the Payload Officer and the Test Director 
in order to monitor environmental s. and the Facilities Engineer 
was monitoring power. These operators were participating in the 
simulation, however, and did not report the problem. 

5. 3. 3.3 Science Con^)uter Operation 

Due to development problems, no processed data was available in 
the POCC. although the Science Computer could be used to dump down- 
linked records and hardcopy them for use in troubleshooting. The 
primary use of the Science Computer, then, was to receive downlink 
data from the GDS, store, and transmit to ARC, as discussed in the 
next section. 

The Science Computer was limited in the number of display terminals, 
so the Data Manager did not have any display of the system status. 
This problem was compounded by the fact that the computer operator 
did not have access to a communications loop. The only way the 
Data Manager could tell if tiie ARC data link was up was by shouting 
over the consoles to the computer operator. A status display was 
also needed to tell how near real-time the link was operating, since 
ARC might be looking at data that was several minutes old. Unless 
the Data Manager knew this status, coordination with ARC was very 
difficult. 

The lack of a cotrmuni cations loop for the computer operator also 
meant that coordination with the ARC operator could be done only 
by FTS telephone. If communications could not be established by 
phone, coordination had to be relayed through the Data Manager. 

This became complicated because the ARC operator had to leave his 
position to get to a coimnuni cations loop. Additionally, the only 
loop available for communication with ARC was the Science Coordi- 
nation loop, which was used primarily for PI coordination. 

5. 3.3. 4 Data Stripping and Transmittal 

The task of gathering data from the Varian link and forwarding it 
to the SORC was handled by the Science Computer in three steps. 

(1) demultiplexing, (2) spooling, and (3) transmission to ARC. 
Receipt of the downlink buffer was in a scrambled format so that 
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It required demultiplexing. The demultiplexing was handled on an 
experiment basis by tasks dedicated to this purpose. These tasks, 
called spoolers, were called in dynamically based on the configura- 
tion number in the downlink buffer. A typical spooler performed 
the demultiplexing operation and wrote the data in SORC link format 
to a spool file on the disc. The reason for the intermediate spool 
file was to preclude data loss due to a link dropout or failure. 

The final step was to read the data from the spool file and send it 
to Ames via the link. 

Certain experiments (X50, X76A, X76B) had data rates exceeding the 
9600 BPS link capability. For these experiments, only a portion 
of the data was transmitted real-t^me to maintain a reasonable flow 
of information to the P.I. 

The entire data stream from 76A, 76B, and 50 were recorded on tape 
in real-time. It was planned to send these tapes to the SORC over- 
night. This plan was abandoned when it became apparent that manning 
ARC was required, as well as at JSC. 

One operational problem occurred when the 76A and 76B experiments 
were run back-to*back. The 11/40 was severely limited in disc space 
and had but a single tape drive. Therefore, the disc and tape had 
to be reconfigured between 76A and 76B. This required about two 
minutes which were not always readily available. In a Shuttle era 
operation, this sort of limitation would not occur. 

5.3.4 SORC Displays, Processing and Operations 

Operation of the SORC was the responsibility of the SORC Director 
with the support of a SORC Science Chief and a SORC Operations Chief. 
They were assisted by Pi's, PE's, technicians, and others as required. 
Figure 5-10 is a photograph of the SORC in operational configuration. 

In concert with the general operational policy of the SORC, every 
attempt was made to process and display the experiment data sent to 
the SORC in a timely manner, i.e., real-time , so that appropriate 
displays could be presented for the respective P.I. A listing of 
the SORC real-time data displays is given below by experiment number. 


Experiment 

Data Displayed 

Type of Display 

Display Device 

X5 a 

Heart Rate 

Stripchart 

Brush 

b 

Respiration Rate 

II 

II 

c 

EMG 

II 

II 

d 

Blood Volume (Finger) 

II 

II 

e 

Blood Volume (Face) 

II 

II 

f 

GSR 

II 

M 

9 

Heart Rate 

CRT plot-5 sec. ave. 

VT-11 

h 

Respiration Rate 

11 

It 

1 

GSR 

It 

II 

j 

Blood Volume (Finger) 

II 

II 
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Experiment 

Data Displayed 

Type of Display 

Display Device 

X13 

a 

COj Rat A 

CRT plot-1 rain. ave. 

VT-11 


b 

14^00, Rat A 
CO, Rat B 

li 

II 


c 

H 

II 


d 

14^C02 Rat B 

II 

II 

X15 

a 

EOG 

Stripchart 

Brush 


b 

Acceleration 

II 

II 

X50 

a 

Audio Blood Flow 

Stri pchart 

Brush 


b 

ECG 

II 

II 


c 

Blood Flow 

II 

II 


d 

Echocardiogram 

TV of onboard reed. 

Slow Scan TV 


e 

Systolic Blood Press, 

CRT plot 1 min. ave. 

VT-11 


f 

Diastolic Blood Press. 

II 

II 


9 

Average Blood Flow 

II 

II 


h 

Heart Rate 

II 

II 

X57 

a 

Heater Current A 

Stripchart 

Brush 


b 

Heater Current B 

II 

II 


c 

Heater Current C 

II 

II 


d 

Heater Voltage A 

II 

II 


e 

Heater Voltage B 

II 

II 


f 

Heater Voltage C 

II 

II 


9 

Liquid Temp. Top 

II 

II 


h 

Liquid Temp. Bottom 

II 

II 


i 

Liquid Temp. Mid. 

CRT plot 1 rain. ave. 

VT-11 


j 

Heating Plate Temp. A 

It 

II 


k 

Heating Plate Temp. B 

II 

II 


1 

Heating Plate Temp. C 

II 

II 

X58 

a 

Op 

Switched Gas 

Stripchart 

Brush 


b 

II 

II 


c 

CO, 

II 

II 


d 

Argon 

II 

II 


e 

Flow 

II 

II 


f 

Volume 

II 

It 

X76 

a 

ECG 

Stripchart 

Brush 

A&B 

b 

Heart Rate 

II 

It 


c 

AOP 

II 

II 


d 

LVP 

II 

It 


e 

LVP Expanded 

II 

tl 


f 

DP/DT 

II 

II 


9 

Differential Pressure 

II 

It 


h 

Mean LVP 

CRT plot 1 min. ave. 

VT-11 


i 

Mean AOP 

II 

II 


j 

Heart Rate 

II 

It 


k 

Pod Differential Pressure 

II 

II 
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Experiment 

Data Displayed 

Type of Display 

Display Device 

X76-background 

a 

Heart Rate A 1 min. ave. 

CC /Numerl c 

Omron 

b 

AOP A " 

II 

II 

c 

LVP A " 

II 

II 

d 

Temp A " 

II 

II 

e 

Flow A •• 

II 

II 

f 

Heart Rate B " 

II 

H 

g 

AOP B •' 

II 

II 

h 

LVP B “ 

II 

II 

i 

Temp B " 

II 

II 

j 

Flow B “ 

II 

II 

k 

Ambient Press 

II 

II 

1 

Ambient Temp 

11 

II 

m 

Upper Pod Temp A 

II 

It 

n 

Upper Pod Temp B 

II 

II 

0 

Lower Pod Temp A 

II 

II 

P 

Food/Uater A 

II 

II 

q 

Food/Uater B 

II 

II 

r 

Fractional O 2 
Fractional CO, 
Fractional H^O 

II 

II 

s 

II 

II 

t 

II 

II 

u 

V 

Fractional 
^ Production 
c6. Production 
Respiratory Quotient 

II 

II 

II 

II 

w 

X 

II 

II 

It 

II 


OTR 14/15 





a 

Prim Sys in Temp 

/Numeric I&IO min ave 

Omron 

b 

Prim Cage in Temp 

II 

II 

II 

c 

Rodent Sys in Temp 

II 

II 

II 

d 

Rodent Cage in Temp 

II 

II 

II 

e 

Rodent Cage Out Temp. 

II 

II 

II 

f 

Activity Cage - 10 min. 

II 

II 

II 

9 

Activity Cage 

It 

II 

II 

h 

Activity Cage 

II 

II 

II 

1 

Activity Cage 

II 

II 

II 

j 

Activity Cage 

II 

II 

II 

k 

Activity Cage 

II 

II 

II 

1 

Water Consumption 

II 

II 

II 
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Experiment 

Data Displayed 

Type of Data 

Display Device 

OTR 16/17 





a 

Prim Sys In Temp 

cc/Numeric-l&lO min ave 

Omron 

b 

Prim Cage In Temp 

M 

II 

II 

c 

Prim Sys Out Temp 

II 

II 

II 

d 

Rodent Sys In Temp 

II 

II 

II 

e 

Rodent Cage In Temp 

II 

II 

II 

f 

Rodent Sys Out Temp 

II 

II 

II 

9 

Metabolic Sys In Temp 

II 

tl 

II 

h 

i 

Activity Cage - 10 min. 

II 

II 

II 

II 

II 

II 

11 

j 

k 

II 

II 

II 

II 

II 

II 

II 

II 

1 

II 

II 

II 

II 

m 

II 

II 

II 

II 
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During the conduct of each experiment the data was passed from the 
JSC Science computer to the SORC using predetermined data formats. 
Number “crunching" was necessary for the high data rate experiments, 
but In all cases the P.I.'s received sufficient data to assess in 
real-time their respective experiment. 

Original planning called for the SORC to be manned 24 hours per test 
day. At night the non-real time data transfer and data processing 
was to take place. During, the two day simulation the SORC was 
manned 24 hours per day. ^sed on that experience. It became apparent 
that plans to process all non-real time data each night were overly 
optimistic. The data transfer rate was the limiting factor. There- 
fore, the non-real time data was not sent to the SORC at night, but 
was collected on magnetic tape for processing after the SND III test 
was completed. The housekeeping data and X76 background data was 
sent to the SORC and stored on tape for processing and display early 
each morning. 

All data received over the high speed data line was digital including 
data to be displayed on the stripchart. In that case the digital 
signal was converted to an analog S''gnal ts would be done in a real 
mission versus the non-real situation that prevailed at JSC where 
the stripchart recorder was hardwired to the spacelab mockup. 

The SORC operations were pretty much as planned other than for the 
elimination of tite night time data processing. The SORC was not on 
a shifting basis; i.e. , the SORC was operational at 0530 to 0600 
hours each day until after the status meeting each night (2000 to 
2200 hours) and staffed throughout that time by the same people. 

The only exception was the computer operators - the semblance of a 
shifting pattern was established, but not enforced by the SORC 
director nor adhered to by the personnel involved. For the most part 
they would stay beyond the end of their shift for as long as needed. 

The P.I.'s were not 'ied when their experiment would be conducted 
and they would be in the SORC approximately 1/2 hour ahead of the 
scheduled time. As it turned out, the conduct of the individual 
experiments frequently ran, behind the CAP. That resulted in the P.I.'s 
experiencing long waits or going back to their labs until called 
again. The predictability of the experiment start times left some- 
thing to be desired and frequently even the status of experiments in 
progress could not be ascertained with any certainty by either SORC 
or JSC operations people. Thus, several occasions arose where the 
experiment was started without the P.I.'s being In the SORC. 

A finite amount of tinw was required to change the onboard configura- 
tion from one experiment to another. Similarly, the ground based 
computer systems needed a finite amount of time also. Instances 
arose during the first few days of the SMD-III test, where neither 
JSC nor the SORC had sufficient time and subsequent data processing 
in the SORC would run behind by several minutes, gradually catching 
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up as the experiment progressed. The catching up process was 
experiment dependent and required a considerable time for say 
X76 whenever the data processing started out “behind" the conduct 
of the experiment. 

The data system was In operation 24 hours per te<t day. The com> 
puters at the JSC and the SORC would from time to time crash* which 
would cause the data processing to lag the experiment forcing a 
catch mode also. Seldom was there sufficient time to troubleshoot 
and document the <:ause for a computer crash* but on the other hand, 
down times were urually short. On only one occasion could the 
cause of a system crash be traced to a high-speed data link dropout. 

In addition to the real-time experiment data received, processed 
and displayed for the P.I.'s, there were data products produced 
for the P.I.'s. Some of the data products were produced Immediately 
after the end of the applicable experiment run. Examples c..*e hard 
copies of the graphics plots and printouts of certain experiment data 
all done on the Versatek printer/plotter. Some data such as the 
B3HF activity measurements , and average temperatures were supplied 
on the teletype once per hour throughout the day. Some data requiring 
additional processing was processed again at the earliest opportunity 
consistent with receiving real-time experiment data. All data 
received by the SORC was logged or magnetic tape as a master data 
file. 

During the X76 experiment with Its high speed data rates, the strip- 
chart tracings were not continuous throughout the experiment run. 

That was due to the time required to periodically receive and process 
the "housekeeping" and experiment 76 background data Interspersed 
with the experiment data being received, processed and displayed. 
Although the stripchart records (for all experiments) had a generated 
time code channel as a part of the record, some additional post SMD 
III data processing was to be accomplished to produce a continuous 
stripchart recording for post test analysis. 

Finally, as per planning for data processlnq, certain data products 
such as magnetic tapes for the various P.I.'s were to be produced 
after the completion of the SHD III test. 

All deliverable data products produced by the SCRC for the various 
P.I.'s are cited In the table of Figure 5-11. 
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FIGURE 5-n, SMD III SORC DATA PRODUCTS 
( 50 ) 












5.3.5 Slow Scan TV Operations 


The node of operation in the SORC w^s to check out the system when 
powered up by sending to and receiving from JSC color test patterns. 

If the test patterns received at both ends were normal then the system 
was jud^d to be operating satisfactorily and the system would be 
placed in the "sequence" mode transmitting pictures from JSC to the 
SORC. Throughout the day as events of special interest were encoun- 
tered, "one shot" operation would be used and specific pictures 
selected by personnel at JSC would be sent to the SORC. Frequently, 
JSC would request that pictures of the processed data displayed in 
the SORC be transmitted to JSC for which the "one shot" mode would 
be used. After each special event the system would be reconfigured 
back to the "sequence" mode cited above. 

Primary utilization of the slow scan TV system was by the SORC 
personnel and principal investigators (P.I.'s) of the various experi- 
ments. In the sequence rrJe, for instance, those in the SORC could 
have a ^neral knowledge (albeit, not detailed) of the onboard 
activities and experiments that were being conducted. The system 
was also used routinely for sending specialized pictures such as for 
the X50 echocardiograms, close ups of some of the experiments during 
phase training and close ups of the surgical work bench and the work 
being done at that station. 

Soon afte** the installation of the slow scan TV system in the SORC 
it became apparent that it would be used on a daily basis, not 
because of preference for the slow scan, but because it was the only 
TV planned for and available in the SORC. Those in the SORC became 
somewhat dependent upon the TV system to provide some information 
concerning the onboard activities - information which was to be 
obtained from no other source. In that regard the system proved 
its usefulness in that the minimally sufficient information obtained 
from the slow scan TV helped the SORC operate in its expected mode. 

The slow scan TV system in "sequence" mode provides a new picture 
every 150 seconds. To the casual observer that might seem sufficient. 
Hcwover, to the operations people who follow the onboard activities 
very closely for control and coordination purposes and the P.I.'s 
who have specific experiment protocols which are being followed by 
the onboard crew, the slow scan TV was not a<tequate to follow the 
activities associated with many of the experiments. The motion that 
is observed by viewing a full TV stream in and of itself imparts a 
certain amount of information to the viewer that is totally lacking 
in the slow scan system. 

Even so, slow scan TV coverage woula be sufficient for socia of the 
relatively inactive or passive experiments and in cases such as X50 
where the P.I. planned to utilize the "snap shot" capability of the 
slow scan TV to get a quick look at some of the onboard analog data. 

The effectiveness of the slow scan TV in providing useful scientific 
information is questionable at best. This is evidenced by the fact 
that out of a potential of 200 addresses available on the disc 
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recorder only 30 were utilized for experiments other than X50 
(which planned to use it for echocardiograms) and most of those 
were of the general experiment set up. In all fairness* however, 
the lack of interest in preserving pictures was probably due to 
the inability to remotely control the camera(s) and/or to get 
close ups of the experiment or experiment subject. 

Effectiveness of the system was not compromised by maintenance 
problems. In the checkout and early equipment usage stages, some 
problems were encountered with the NEC equipment in the SORC. An 
NEC representative checked out and repaired the equipment which 
operated maintenance-free thereafter. One problem that required 
a considerable effort to overcome was to get the disc recorder to 
synch up on the signal from the NEC equipment. 

Drop outs were relatively infrequent and could be traced to the 
telephone line and tlie link was re-established with little or no 
consequential delay. Noise on the line would show up in the pic- 
tures as lines through the picture, but were never any source of 
concern or the cause of information loss. The most severe opera- 
tional test had to be the SMD III test when only one short drop 
out occurred in seven days of continuous operation. 
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5,3.6 Library Archiving and Data Distribution 


Based on the successful experience of Spacelab Mission Simulation II, 
a branch of the Space Life Sciences Archival Library was established 
at the POCC for the duration of the test. This branch was staffed 
by Kentron Hawaii personnel from the library on a two-shift, 16 hour 
basis. The first shift came on at 2 p.m. local, after the day's 
experiment activity had started. The librarian collected data gen- 
erated so far by the Data Manager, checked it into the library, and 
cataloged it for input to the computerized library index. As data 
was generated during the day, each piece, whether tape, printout, 
or stripchart, was logged in and cataloged. The work sheets of 
cataloged data were then input into the library index using one of 
the i€DICS terminals in the POCC. Input was completed by the second 
shift, which began at 10 p.m. local. This assured that all data was 
accounted for and the index was current. 

Checkout of data was handled by the librarian whenever data was 
needed by the P.I. or others for analysis. The librarian could also 
draw on the resources of the library for background and past program 
data and documentation, if needed. 

By checking all data into the library, as generated, the problems 
found in past programs of missing and lost data are circumvented. 

Even though much of the data from this test was given to the P.I.'s 
on permanent loan, the library maintains a record of its existence 
and the responsible party for its location. 
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5.3.7 Test Status Reporting 
5. 3.7.1 JSC 

A ne«f data base* called SND3* was generated In the HEOICS data 
storage and retrieval system. Three forms were used to enter 
data* the ACCONP for completed experiments* the HALF for problem 
tracking, and the TV for television scenes recorded. Exa^les 
of completed forms as retrieved from the data base are shown In 
Figure 5-12. An additional form for crew health status was 
planned, but the medical officer decided It was not necessary. 

The Experiment Activities Planning Officer was responsible for 
completion of the ACCONP handwritten worksheet after each experi- 
ment run, with Inputs from the Principal Investigator. The HALF 
worksheets were prepared by the Payloads Officer for system problems, 
and by the Assistant Payload Science Hanager for experiments. TV 
Inputs were taken from the log maintained by the TV Officer. 

The Data Librarian collected the worksheets every evening after 
crew “lights-out" and entered ttem Into the data base, thus assuring 
that all the day's accomplishments were entered. The Data Librarian 
and Data Manager then prepared a dally status report which was dis- 
tributed to all operating positions In the POCC and Test Control Area 
prior to the next day's activities. Canned retrieval routines, 
called macro's, were developed which facilitated retrieval of cumu- 
lative test results to date In a tabular format. An access code was 
also established for ARC so that they might retrieve the status data 
for the SORC via telephone. 

No operating problems were encountered with the system, and only one 
work-around was required. This occurred when scheduled maintenance 
In Building 30, where the MEDICS computer was located, required a 
shutdown of air conditioning for a day and the computer could not 
be used. 
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5. 3. 7. 2 ARC 


The SORC borrowed a TYMSHARE 1030 terminal from another organization 
at the ARC and was assigned an access code to the MEDICS computer 
prior to the two day simulation. The SORC had no direct input into 
the MEDICS computer. The data dump from the MEDICS computer was 
acquired in the SORC early each morning and scanned for content. 

The data consisted of a. listing of the SMD III Accomplishments to 
date, a Malfunction listing and a TV listing. Each morning tiie SORC 
Director and the SORC Science Chief would review and identify verbally 
to the POCC Data Manager the TV sequences that should be retained and 
later made available to the P.I.'s. Otherwise the MEDICS information 
was used very little. 
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6.0 POST TEST ACTIVITIES 

6.1 ONBOARD DATA RETURN AND DISTRIBUTION 

During the conduct of the experiments on SNO III a number of hard 
copy data products Mere produced in the Spacelab mockup. These 
included stripchart recordings, marked-up test procedures, printer 
tapes, and exposed film. 

As each data product was completed it was placed in a duffel bag 
on the mid-deck Mhich the crew had set aside for the purpose. At 
the end of the mission the Data Manager went aboard and removed 
the duffel bag prior to crew egress. The Data Manager and SLSAL 
library personnel inventoried the contents and each data item was 
logged into the MEDICS system. The individual data items were 
then checked out to the Pi's or placed in the Space Life Sciences 
Archival Library (SLSAL) as appropriate. 

The crew indicated post-mission that the duffel bag was an unsatis- 
factory arrangement and suggested that a locker be provided on 
future missions to house data supplies and coaq)1eted data products. 
The use of this locker should be clearly specified in the flight 
procedures. 
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6.2 LOG TAPE DATA RECOVERY 

It was recognized from the beginning that a problem existed In 
recovering data from the OOS log tapes* since they were In a 
seven track format from the Varlan computer/ tape drive* and the 
processing would be done on a POP 11/40 computer* which uses a 
nine track format. During pre-test development* format conversion 
was done on the MEDICS computer for a number of tapes. This 
required carrying the tapes to another facility* however* and tied 
up a computer which was In active use for other tasks. 

Just prior to the test, software was written for the GDS computer 
which allowed the GDS to read the log tape and put the data on 
the link to the Science Computer. The Science Computer than could 
transmit to ARC and/or generate a nine track tape. 

After the test, ARC determined that they were missing approximately 
18 hours of Experiment 76 physiological background data, mostly In 
the 48 hour pre test control period. Since playing this data to 
ARC It real time rate would be very time consuming. Ford Aerospace 
modified the GDS software to allow reading the log tape at four times 
the recorded speed. The data was then recovered and nine track tapes 
were made and shipped to ARC. 
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6.3 POST TEST DATA PROCESSING 

The complete set of JSC analog tapes and the JSC Science Computer 
digital tapes were shipped to ARC post mission. These* in conjunc- 
tion with the digital log tapes created at ARC, constituted the 
basis for all post-test data processing. The JSC Science computer 
tapes were of two types; the experiments 50 and 76 high rate data 
recorded during a run and the balance of the SMD III data recorded 
as daily files. 

The data for each experiment were stripped from the ARC master data 
tapes to generate the individual Experiment Data Records (EDR) 
delivered to the Principal Investigators. The JSC daily files tapes 
were used as a backup source to fill in any data gaps in the ARC 
tapes. The JSC Experiment 50 and Experiment 76 data tapes were 
used as the prime source of high rate data for portions of the 
Experirnents 50 and 76 EDR's. 

Once the EDR tapes were created and minor modifications were made 
to the applications software the data for each experiment we*« 
replayed to generate final data products consisting of stripcharts, 
listings and plots. 


NASA-JSC 
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